Databases store date for a variety of different purposes. In many cases, a database is used to store data that is generated and/or used by an application. Merely by way of example, many businesses (and other organizations) use software applications (and/or suites of such applications) to organize their business affairs, track business performance, and/or the like. Such applications (referred to herein as “enterprise applications”) are often quite complex and/or data-intensive; often, an enterprise application is responsible for managing and/or analyzing data for virtually every aspect of an organization's business. Examples of enterprise applications include, without limitation, supply chain management (“SCM”) applications that manage raw materials, work-in-process and/or finished products, coordinate with suppliers, and/or the like; customer relations management (“CRM”) applications that are used to track, store and/or manage customer information; financial applications that track and/or analyze the financial performance of the organization; human resources applications that provide management of the human resources functions of the organization; and/or the like. In some cases, these enterprise applications are standalone applications; in other cases, a single enterprise application (and/or suite of applications) might provide some or all such functionality. One type of enterprise application is referred to enterprise resource planning (“ERP”) software. Examples of enterprise applications include, without limitation, JD Edwards EnterpriseOne, PeopleSoft Enterprise applications, and the Oracle eBusiness Suite, all available from Oracle Corporation.
Because of their data-intensive nature, enterprise applications (as well as other types of applications) often use a database to store the data they generate, manage and/or use. In particular, many enterprise applications are configured to be used with a relational database management system (“RDBMS”), of which the Oracle 10g™ RDBMS is but one example. Typically, an application (such as an enterprise application) will store data in a plurality of tables, with relational links between various records and/or fields in the tables. In general, each application will have specific requirements for the data structures (e.g., tables, rows, fields, etc.) in a database used to store data for the application. More specifically, the database's data structures often are based on the features and/or requirements of the application.
This can present a problem when an application is updated. Merely by way of example, if an application is patched (e.g., to fix errors in the code, provide enhanced security, etc.), the patched application might impose different data structure requirements than the unpatched version. As another example, when an application is upgraded to a newer release level, any additional functionality offered by the new version of the application might require the storage of additional data, which the existing data structures in the database might be unable to accommodate. Hence, an application update often will require a corresponding change in the data structures used by the application.
Traditionally, this has been a computationally-expensive process, which can require a variety of operations from updating the structure of a single table to support additional fields in each record and/or for updating the format of various fields (and, possibly population of the new and/or modified data structures with data) to rearchitecting the table structure of the database. Accordingly, database updates traditionally have been performed as a batch process, generally requiring the database (and, by extension, any application using the database) to be made unavailable for a significant duration.
In many situations, this unavailability may have significant consequences. Hence, there is a need for tools that allow a database to be updated without rendering the database (and/or the application it supports) unavailable for extended periods of time.